1. Field of the Invention
The present invention generally relates to a cluster of application servers. More particularly, the present invention provides a voting mechanism for assigning an application server of an application server cluster the task of invalidating all sessions containing listeners in the cluster for a web application.
2. Related Art
An Http session object is created to store information specific to a certain web user. Http sessions are run under and managed by application server processes. The lifetime of an Http session can be specified by a TimeOut interval, which when elapsed makes the session eligible for invalidation. Applications can register a listener object in a session, which will get notified when session invalidation happens. In this way an application can free up the resources that are being used by that web user or provide special processing for that web user. In a clustered environment, a session is replicated to multiple servers so that session information is not lost when one of the server crashes. A session that has timed out should be invalidated only once and this can be done by any application server process in the cluster.
In a clustered environment a web application can run in more than one application server and each application server is responsible for invalidating sessions of the web applications installed on it. An application server contains a background invalidation process (or thread) to determine the candidates for invalidation and to perform invalidation. An application server can choose to have a single invalidation process that goes through all web applications or can have a separate invalidation process for each web application. One problem that occurs is that multiple invalidation processes can run concurrently and the same session can get invalidated multiple times in different servers. This is especially problematic if the sessions contain listener objects that get invoked upon session invalidation and the listeners get invoked multiple times.
An example of the above-described problem is illustrated in FIG. 1. In this example, three application servers AppServer1 12, AppServer2 14, and AppServer3 16 are organized in a cluster 10. In cluster 10, application server AppServer3 16 serves as a backup server to application servers AppServer1 12 and AppServer2 14. Application servers AppServer1 12, AppServer2 14, and AppServer3 16 can communicate with each other as indicated by arrows 18.
A web application WebApp 20 runs in application servers AppServer1 12 and AppServer2 14. In application server AppServer1 12, web application WebApp 20 includes sessions 22 and 24, which contain listener objects. In application server AppServer2 14, WebApp 20 includes sessions 26 and 28, which also contain listener objects. To provide persistent session information, sessions 22 and 24 in WebApp 20 (AppServer1 12) are replicated to AppServer3 16, as indicated by reference numerals 22R and 24R. Likewise, sessions 26 and 28 in WebApp 20 (AppServer2 14) are replicated to AppServer3 16, as indicated by reference numerals 26R and 28R.
AppServer1 12 includes an invalidator 30 that provides invalidation processing for WebApp 20 using the replicated sessions stored in AppServer3 16. Similarly, AppServer2 14 includes an invalidator 32 that provides invalidation processing for WebApp 20 using the replicated sessions stored in AppServer3 16. It is assumed in this example that session 22 of WebApp 20 is to be invalidated (e.g., in response to the elapsing of a TimeOut interval). To this extent, invalidator 30 for WebApp 20 in AppServer1 12 and invalidator 32 for WebApp 20 in AppServer2 14 can concurrently invalidate session 22 using the replicated session 22R stored in AppServer3 16 as indicated by arrows 34, leading to duplicative invalidation and listener processing. As such, there is a need to prevent such duplicative processing from occurring.